feat(core): add Forbid create object and Forbid edit object space permissions - #11149

Fixes #9079

Summary

Space type roles could only forbid deleting objects. This adds two space-scoped permissions, "Forbid create object" and "Forbid edit object", offered in every space type that already offers "Forbid delete object" (tracker, document, drive, board, recruit, lead, test management, GitHub).

Changes

• Model: new core.permission.ForbidCreateObject (TxCreateDoc) and core.permission.ForbidUpdateObject (TxUpdateDoc), with labels and descriptions in all locales.
• Server (SpacePermissionsMiddleware):
  • "Forbid edit object" also covers non-empty TxMixin (mixin attribute updates). Collection transactions are the child TxCreateDoc/TxUpdateDoc produced by createTxCollectionCUD and are checked the same way.
  • The check uses the transaction's objectSpace, so an update that moves an object out of a space where the member has "Forbid edit object" is rejected.
  • The generic create/edit forbids do not apply to the space document itself, so role holders can still manage members, role assignments and archiving. "Forbid delete object" keeps its existing scope and still applies to the space.
  • When several permissions without txMatch match, a forbidding one now wins instead of the last one in order. A matching txMatch permission keeps precedence.
  • Unchanged: the system account bypass uses the session identity (not modifiedBy), and trigger output (activity, notifications, collection and move side effects) goes through the derived entry below this middleware.
• Client (view-resources/src/permissions.ts): canCreateObject returns false for "Forbid create object" and canRemoveDoc for "Forbid delete object", before either looks at class permissions. canChangeDoc returns false for "Forbid edit object" only after its existing checks of the class's own ${_class}_forbidden/${_class}_allowed permissions, so such an explicit class allow still makes the object editable in the UI. The existing early true results of all three helpers (permissions disabled, whitelisted space) are unchanged.

Behaviour changes and limitations

• Forbid wins across all roles of a member. If a member's roles combine "Forbid delete object" with a class delete permission without txMatch (e.g. Drive "Remove file"), the outcome used to depend on permission order. Now the forbid always wins. The Drive UI follows this through canRemoveDoc.
• Forbid create blocks all creates in the space, including comments, reactions, attachments and issue time reports (TimeSpendReport). "Forbid edit object" blocks editing them too.
• UI coverage is partial. Only list/table inline editors, cards and Drive hide the affected controls. Other editors and create buttons (e.g. the issue editor and "New issue") stay enabled; the server rejects the change, but in several of them (e.g. custom-field editors, comments, moving an issue) the rejection is silent in the UI — nothing is saved, yet the user gets no error message. Better client feedback would be a separate change.
• Moving an object into a forbidden space is not blocked. The move is checked against the source space only. Moving an object from an unrestricted space into a space where the member has "Forbid create object" still works.

Tests

foundations/server/packages/middleware/src/__tests__/spacePermissions.test.ts:

• ForbidCreateObject blocks creating objects in the space only
• ForbidUpdateObject blocks updates and mixin updates of objects in the space
• rejects a TxMixin attribute update with Forbidden before forwarding
• checks collection create/update transactions (real TxFactory)
• ForbidUpdateObject blocks moving an object out of the source space
• does not restrict members without the role
• does not restrict the system account
• does not grant the system bypass based on transaction modifiedBy
• keeps the derived entry available for server transactions under both forbids
• checks transactions inside TxApplyIf
• does not lock role holders out of managing the space itself
• keeps ForbidDeleteObject applying to the space itself
• forbid wins over an allowing permission regardless of order
• ForbidDeleteObject wins over an allowing delete permission (both orders)
• a class/attribute permission with txMatch takes precedence over the generic forbid

plugins/view-resources/src/__tests__/permissions.test.ts:

• canRemoveDoc: ForbidDeleteObject wins over a class delete permission (both orders), and a class delete permission alone still allows removal
• canCreateObject / canChangeDoc: the create/edit forbids win over ordinary class create/update permissions (without txMatch), with allow-only controls

Verification (head 53090ee): local CI is green (install, build, validate, svelte-check, format, unit tests including middleware spacePermissions tests and view-resources permissions.test.ts, bundle). Browser checks on a local stack with two members, identical in Chromium, Firefox and WebKit: 9 checks pass — for a restricted member the server rejects a custom (mixin) field edit, creating and editing a comment, and moving an issue out of the project, and nothing is saved (verified after a reload), while an unrestricted member can do the same; managing members, role assignments and archiving the project keep working under both forbids; notifications and activity are still delivered. Not automated: attachment metadata editing, the system-session path, and the delete-precedence orderings (the Tracker role picker cannot assign an explicit delete allow); these are covered by the unit tests. Two observations: the attachment-create check could not locate the upload control reliably in this run, and, as noted above, several still-enabled editors give no visible error when the server rejects the change.